在說明功能標誌時，Nathan 團隊已確認活動頁面與首頁入口需要分開控制，並約定設定如何生效、各種組合應有的行為。

開發者要先將這些判斷寫進程式，完成驗證與部署，才能透過設定控制活動頁面與首頁入口。之後產品經理調整開放時間，或決定結束首頁宣傳時，團隊就不必再為了這些安排修改程式。

依開關設定控制頁面與入口

兩個開關分別使用以下設定，true 表示開啟，false 表示關閉。

以下兩段程式分別處理首頁與活動頁面請求，假設應用程式已在每次請求取得最新的 $flags 設定陣列，並將值轉為布林值。程式省略 <?php，頁面與入口的輸出以註解表示。

Elvina 在產生首頁內容時，先讀取兩個設定，再判斷是否加入活動入口。如果沒有提供設定，就透過 ?? false 預設為關閉。

// 以下範例使用 PHP 8.2 以上

$activityEnabled = $flags['activity_enabled'] ?? false;
$activityEntryEnabled = $flags['activity_entry_enabled'] ?? false;

// 回傳首頁

if ($activityEnabled && $activityEntryEnabled) {
    // 加入活動入口
}

Mandy 則在處理活動頁面請求時，先檢查頁面開關。如果開關關閉，就回傳 HTTP 404 與「找不到頁面」，再用 exit 結束執行，不繼續輸出活動內容。

$activityEnabled = $flags['activity_enabled'] ?? false;

if (!$activityEnabled) {
    http_response_code(404);
    echo '找不到頁面';
    exit;
}

// 回傳活動介紹頁

分步整合與部署活動程式

兩人先完成設定判斷，再逐步加入入口與頁面程式。每次整合前，先取得主幹更新，完成這次要整合的程式與測試。除了驗證已實作的活動功能，也要確認網站能正常建置與啟動，並在關閉活動功能時，檢查首頁等原有功能是否仍能使用。

活動尚未完成時，正式環境的兩個開關保持關閉，其他已準備好的功能仍可照常交付。

活動功能完成且主幹驗證通過後，Brent 將成品部署到測試環境。Elvina 與 Mandy 測試四種開關組合，確認首頁只有在兩個開關都開啟時才顯示入口，活動頁面則只在頁面開關開啟時提供內容。兩人也要確認未提供設定時，開關是否預設為關閉，以及首頁原有功能與受影響的共用樣式是否正常。

確認必要驗證通過、交付準備完成後，Brent 將測試過的同一份成品部署到正式環境，兩個開關先保持關閉。Elvina 與 Mandy 再檢查首頁是否正常、活動入口是否隱藏，並直接開啟活動網址，確認無法取得內容。

開放活動頁面與首頁入口

到了約定的公開時間，產品經理確認可以開放後，Brent 可以先開啟活動頁面開關。Elvina 與 Mandy 確認頁面內容正常，再由 Brent 開啟首頁入口開關，讓使用者可以從首頁進入。

宣傳結束後，產品經理通知 Brent 關閉首頁入口開關，活動頁面仍保持開放，任何持有網址的人都能繼續閱讀。

活動頁面開放期間若發生問題，團隊先關閉頁面與入口開關，避免恢復頁面時，入口也跟著出現。確認新的請求無法取得活動內容、首頁不再顯示入口後，再處理問題。修正並通過驗證後，依當時的公開安排決定恢復哪些設定。

不過，使用者已看過的內容無法收回。如果功能會寫入資料或寄信，關閉開關也不會還原已寫入的資料，或收回已寄出的信件。

移除不再需要的活動開關

活動結束後，假設產品經理與需求方決定保留介紹頁供日後查閱，不再於首頁宣傳，也不需要控制頁面開放。兩個開關已經沒有用途，就可以安排移除。

Elvina 移除首頁的活動入口與顯示判斷，保留首頁其他內容。Mandy 移除活動頁面中「開關關閉就拒絕請求」的判斷，讓它成為一般可閱讀的頁面。

程式不再使用開關，測試也要跟著調整。兩人移除原本測試開關切換的情境，保留活動內容與首頁既有功能的測試，並確認首頁已沒有活動入口，但直接開啟活動網址仍能閱讀正確的內容。

用 A/B 測試比較版面

除了安排開放時間，產品經理也可以透過 A/B 測試，比較不同版面的使用效果。實驗開關可以依使用者分組提供不同版本，但前面的兩個全站開關沒有分組能力，開發者需要另外設計與驗證。

以下用另一個假設情境說明。產品經理希望比較活動介紹的 A、B 兩種版面，了解哪一種較能幫助使用者找到活動資訊。

團隊先決定要記錄哪些使用行為、怎麼比較兩組的結果，以及何時結束實驗。開發者再將使用者分成兩組，在實驗期間讓一組固定看 A 版，另一組固定看 B 版，並記錄兩組的使用行為。

實驗開始前，要先測試兩種版面，確認活動內容能正常顯示。但頁面能正常顯示，不代表使用者比較容易找到資訊。產品經理還要比較兩組的使用紀錄，不能只看某一次的數字，就判定哪個版面比較好。

移除未採用的版本與實驗開關

若產品經理依實驗結果決定保留 B 版，團隊可以先調整設定，讓適用的使用者都看到 B 版，再確認實際運作。調整設定後，A 版程式仍可能留在原始碼中，因此還需要安排清理。

確認不再需要比較或切回 A 版後，開發者就可以移除 A 版專用的程式、分組判斷與實驗開關，保留 B 版及兩者共用的必要程式。測試也要改為確認固定使用 B 版時的行為，不再測試已經不存在的 A 版切換情境。

功能標誌的其他用途

發布、實驗、維運與權限開關，是依用途所作的分類，同一個開關也可能在不同階段有不同用途。

團隊也可以先邀請部分使用者試用新功能，或讓使用者自行選擇是否參加試用，再收集他們的使用回饋。

如果希望逐步擴大開放範圍，也可以先讓部分使用者使用，觀察實際運作後，再決定是否開放給更多人。遇到問題時，可以先停止擴大範圍，必要時關閉功能，再處理問題。

有些用途則需要持續保留開關，例如依訂閱方案提供不同功能，或在維護期間暫停部分功能。只要這些用途仍存在，開關就需要繼續維護。

小結

活動頁面與首頁入口分開控制後，團隊可以先整合、驗證與部署程式，再依產品安排公開頁面與結束宣傳。確認不再需要控制開放後，就移除開關，保留需要的頁面內容，並清理不再使用的程式、測試與設定。

活動案例控制的是頁面與入口是否開放。如果要替換的是正在使用的寄信程式，新實作尚未完成，舊實作必須還要繼續運作。接下來用抽象分支，說明如何讓新舊實作並存，再逐步替換。

參考資料

• Pete Hodgson：Feature Toggles (aka Feature Flags)
• Trunk Based Development：Feature flags
• FeatureFlags：Uses
• PHP Manual：Null Coalescing Operator
• PHP Manual：http_response_code
• PHP Manual：exit